The Internet Protocol (IP) Multimedia Subsystem (IMS) provides for access-independent advanced multimedia services in a distributed architecture. The session control mechanism of IMS is based on the Session Initiation Protocol (SIP) and provides a flexible, distributed network architecture for deployment of advanced consumer and business services. It is believed that IMS will be the leading technology for delivering evolving Voice over IP (VoIP) services.
It has been recognized that IMS service providers must deploy secure reliable services in order to attract and retain customers. Since IMS supports VoIP services, IMS must address confidentiality of conversations, integrity of communications, end user privacy and the availability of the advanced services that IMS can deliver. Some key security requirements for service providers include hardened network elements and management systems, peer entity and data origin authentication, message integrity, confidentiality, privacy of end user identification, scalable key management, and standards compliance. In many cases, message authentication and integrity will be more important than confidentiality in order to protect the network from fraud and denial of service (DoS) attacks.
The IMS security standards are driven by the 3rd Generation Partnership Project (3GPP) and the 3rd Generation Partnership Project 2 (3GPP2). See, e.g., 3GPP TS 33.203 v5.8.0, “Access Security for IP-Based Services,” Release 5; and 3GPP TS 33.210 v5.5.0, “Network Domain Security; IP Network Layer Security,” Release 5, each incorporated by reference herein. Through such technical specifications, these bodies define and specify how an IMS system is to operate and behave.
Access security is typically concerned with mutual authentication of the user and network equipment and securing the first hop signaling. Securing the first hop may be achieved, for example, through the Secure SIP (SIPS) protocol. Currently, users wishing a secure end-to-end communications path must use either end-to-end cryptographic protection, which may be difficult or expensive to achieve in some situations, or request hop-by-hop protection with the hope that each intermediary node makes the same request to each subsequent node.
A significant problem with hop-by-hop protection, however, is the difficulty in knowing at one endpoint how well the protection extends to the far endpoint. Existing standards provide a mechanism for indicating that each hop of the signaling path is supposed to use Transport Layer Security (TLS) or the call should not be admitted. For example, a call setup request may employ the prefix “sips” (Secure SIP) when identifying the called party, as an indication that hop-by-hop protection is desired to the called party. This allows the user to declare and observe the security level. In a world of possibly untrusted SIP proxies along the end-to-end path, vendors that fail to fully and correctly implement the standard, or the use of unauthenticated TLS, such a mechanism may not provide adequate assurance.
A need therefore exists for improved methods and apparatus for end-to-end security in heterogeneous networks. A further need exists for hop-by-hop protection techniques that ensure that each hop of a signaling path is satisfying one or more predefined security criteria.